CODAP-1505: store point shape per legend category - #2692

Add the model layer for point shapes: each legend category can carry its own
shape, and a display with no legend attribute carries a single one. Nothing
reads these yet -- the controls come with CODAP-1506 and the rendering with
CODAP-1504.

Per-category shape lives on the attribute's CategorySet, next to per-category
color, so two displays using the same legend attribute agree by construction.
The single shape lives on DisplayItemDescriptionModel next to point color. That
pairing mirrors color exactly, which is what the existing per-category color
setter already established.

The default is stored as absence: assigning circle removes the entry rather than
recording it. A document therefore carries only the shapes a user chose, and one
that never used the feature is byte-for-byte unaffected.

V2 round trip
-------------

V2 has no field for point shape, so both halves travel in v3 extension
namespaces: per-category shapes on the attribute, the single shape on the graph
component. Both survive a v3 -> v2 -> v3 round trip. A v2 re-save drops them,
which is lossy but harmless.

They deliberately do NOT ride in _categoryMap, which would be the obvious home
next to colors. V2's updateCategoryMap treats every key of that map except
__order, stroke-color and stroke-transparency as a category: it appends unknown
keys to __order and writes the result back out. A shapes key there would appear
as a phantom category in the user's legend and be persisted by v2 itself. An
unknown key in the attribute's v3 namespace is merely mixed onto the SproutCore
model and dropped by its toArchive allowlist, so v2 is unaffected. A test pins
this, since the safe-looking change is the harmful one.

Imported shapes are not filtered against the categories present in the data, and
so differ from colors, which are. Every shape entry is a deliberate user
assignment, whereas some paths assign colors automatically by category position
-- which is why the color import keeps only a color differing from the one that
position would have produced. Shapes have no generated noise to age out, so a
category whose cases are deleted and later restored keeps its shape. V2 does the
same, for the reason its own comment gives.

Provisional promotion
---------------------

A category set stays provisional until the user changes something that has to
persist, at which point it is promoted into the document. Shapes join moves and
colors as such a change: assigning a shape can be the only thing a user does, so
the promotion predicate has to count it for the shape to be saved at all.

Also remove CategorySet.userActionNames, which named the changes that promote a
set but was read by nothing. Its test asserted against the list rather than the
behavior; the equivalent coverage now runs against the promotion predicate
itself, where moves, colors and shapes are checked together.

Document that promotion replaces the category-set instance, so a reference held
across a modification goes stale and later writes are silently lost. The
per-category setters re-resolve for this reason.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ctmv18kjkPWnUq5bek5nrH

Store the display's shape as absence at the default. types.optional with a
default materializes the field in every snapshot, so opening and saving a
document that never used shapes would change it. maybe leaves it absent, the
getter already resolves that to circle, and the setter now clears it when the
default is chosen -- the same absence-means-default rule the per-category
shapes already follow.

Build the exported and imported shape records with Object.fromEntries rather
than by assignment. A category value of `__proto__` assigned with `map[key] =`
sets the prototype instead of defining an own property, so that category's shape
vanished in both directions. Category values come from the data and can be any
string. Note colorMap has the same pattern and the same latent problem; left
alone as pre-existing rather than widened into this story.

Add tests for changePointShapeNotification, which the ten adjacent notification
helpers already have and this one did not.

The remaining comment is declined: the shapes map does materialize as `{}` in
every CategorySet snapshot, but so does the colors map beside it, so the
snapshot was never unaffected by an empty map. Omitting it needs a
snapshotProcessor and would make shapes behave differently from its sibling.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ctmv18kjkPWnUq5bek5nrH

Category values come from the data and can be any string, including ones that
mean something to a plain JavaScript object. Two faults, both pre-existing,
found while fixing the same class of bug for shapes.

Writing: `map["__proto__"] = color` sets the prototype rather than defining an
own property, so that category's color vanished from colorMap and from the v2
export built out of it.

Reading: for a category named `constructor` or `toString` with no entry, a bare
lookup returns the inherited member. That is truthy and is not a color, so the
v2 importer dereferenced `.colorString` to undefined and handed it to colord --
inventing a color for a category the document said nothing about.

colorMap is now null-prototyped and built from entries, which closes both. The
importer guards its lookup with hasOwnProperty and collects entries rather than
assigning into an object.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ctmv18kjkPWnUq5bek5nrH

Drop a claim that is not true. The note on importing shapes ended by saying v2
does the same thing for the same reason, but v2 has no point shapes at all --
which is why they travel in the v3 namespace rather than the category map. The
sentence described what v2 does with colors.

Prune comments that repeat each other or the code: the note on the shapes map
that colors does without, the reason for keeping a category set that the
condition below it already gives, and a comment duplicated between the v2 type
and the props that build it, reworded between the two for no reason. The note
about `__proto__` said the same thing at length in two files and now says it
once in a line at each.

Test `isPointShape` against a set rather than scanning the list.

Move the test for a shape on a category named `__proto__` in with the other
reserved-key cases, where its color counterpart already lives.

Drop a test that asserted a category set is created when only shapes are
restored. The test above it passes only shapes and reads a property off the
result, so it cannot pass unless the set was created; the intent moves into its
name and comment.

Assert the default through the constant rather than by naming circle, since the
assertion is about the round trip rather than about which shape is the default.

Fix the indentation of three tests, which had drifted from the file.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

A pass for the duplication the review asked about beyond what it flagged.

Why shapes are exported in the attribute's v3 namespace rather than in
_categoryMap was explained four times, twice at length. It is stated once now,
on the v3 field itself, since that field exists for no other reason. The export
test points at it, the round-trip assertion says nothing the test's own name does
not, and the exporter says only what it omits.

That promoting a category set replaces the instance was stated at the promotion
and again where callers resolve one. The caller-facing one is the one that
changes what someone writes, so it keeps the explanation.

The shapes list described what it is before saying where it lives. Only the
second is invisible from the code.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>